前面講了需求、設計、開發、測試，東西做出來也驗過了。今天講最後兩站：上線前要過什麼，上線後要顧什麼。

但因為我無法展示到正式環境。
所以這篇講的是**「如果真的要上線，還要做哪些事情」**，不是「我已經做了哪些事情」。

部署：測試和正式徹底分開

第一件事，是把測試環境跟正式環境真的分開。

正式環境使用獨立的帳密與金鑰。 資料庫密碼、AD 服務帳號、Session 金鑰、API Key，都不能直接沿用測試環境的設定。前面 Day 15 講的 .env，正式環境就是另外一份，而且正式環境的值不應該再丟回 AI 開發環境。測試用的假帳號、假資料，也不要因為方便就一起帶進正式環境。

正式環境的權限不交給 AI。 部署腳本可以請 AI 協助產生，設定也可以請它幫忙檢查，但真正執行部署的人還是我，不是讓 Claude Code 直接連到正式環境操作。這也是前面設定開發環境限制時，我會把「對正式環境的任何連線」直接禁止的原因。

這裡我在意的不是 AI 會不會部署，而是：

AI 可以幫我準備部署，但正式環境的權限不交給 AI。

因為「在設定檔裡告訴 AI 不要碰」，跟「它實際上根本拿不到正式環境的帳號、金鑰與連線權限」，是兩件不同的事情。

環境設定也要重新對一次。 Debug 關了嗎？錯誤訊息會不會把系統路徑、Stack Trace 或其他內部資訊直接吐給使用者？Log 有沒有正常寫？有沒有不小心把 Token、密碼、API Key 或其他敏感資料記進去？這些在開發環境可能只是為了方便除錯，但到了正式環境就必須重新確認。

基礎建設那一層也要看。 不該開的 Port 有沒有關掉？反向代理、TLS 或內部憑證有沒有設定好？上傳檔案的儲存位置與執行權限是不是符合原本設計？磁碟空間與配額有沒有考慮？備份有沒有真的在跑？

這些已經不只是程式碼，而是基礎建設與系統管理的範圍。AI 當然也可以協助產生設定或檢查項目，但正式環境到底開哪些 Port、憑證怎麼放、權限怎麼給，最後還是要依照正式環境的架構與管理規範確認。

上線前，再拿一張 Check list 對一次

前面每一個 Phase 都已經驗過了，但真正要部署之前，我還是會希望有一份上線檢查清單。

不是因為前面做的事情不算，而是正式環境跟開發、測試環境本來就不一樣。正式環境的帳密、權限、網路、憑證、Log、備份、設定值，都可能不同。

所以最後再把重要項目拿出來確認一次，而且要有人真的確認，不是看到部署腳本跑完、畫面出現 Success 就算完成。

另外，上線前也要先想好一件很現實的事情：

如果這一版上去之後壞掉，我要怎麼回去？

前面 Day 21 講 Commit，是讓開發過程留下可以回頭的路標。到了部署階段也是一樣，要知道目前正式環境跑的是哪一個版本，新版本出問題時要怎麼回到上一個已知正常的版本，而不是出事之後才開始研究怎麼救。

能部署上去很重要，知道怎麼退回來也一樣重要。

維運：改了，就重新確認一次

上線不是終點。

系統只要還有人使用，就一定會繼續改。需求會改、套件會更新、漏洞會出現、人會離職、權限會調整，甚至原本依賴的服務也可能有一天不見。

所以維運階段第一件事情就是：變更管理。

平台自己改了東西，要重新過相對應的測試；平台上架的工具改了版本，也要重新走該走的掃描與審核。這兩件事情背後的原則其實一樣：

改了，就不是原來那個東西，需要重看。

前面 Day 19 講過核准要綁 Version 或 Hash，就是這件事情在平台裡的實作。Version A 通過，不代表 Version B 自動繼承核准；如果內容變了，就應該重新確認。

今天沒漏洞，不代表下個月沒有

再來是套件。

今天掃描沒有發現已知漏洞，不代表這個套件永遠安全。可能過幾天、幾個月之後，新的 CVE 才被公布。

所以至少要知道系統到底用了哪些元件、哪些套件、哪個版本，必要時建立並持續更新 SBOM。未來某個套件爆出新的漏洞時，才能快速回答一個最基本的問題：

「我到底有沒有用到？」

不然漏洞消息出來之後，第一件事情不是修補，而是全公司開始問：「我們有沒有這個？」然後每一套系統重新翻一次。

前面 Day 18 講的 SBOM，到維運階段真正的價值就在這裡：它不是產出一份漂亮的清單放著，而是讓後續的漏洞追蹤有東西可以對。

重要紀錄不能只留在系統自己身上

前面 Day 20 講過 Audit Trail：誰上傳、誰送審、誰退回、誰核准、誰發布、誰改權限，這些事情都要留下紀錄。

到了正式環境，我還會再多想一件事情：

這些紀錄放在哪裡？

如果所有重要 Log 都只留在應用程式自己身上，而且應用程式管理者自己就可以修改或刪除，那出事之後這份紀錄的可信度就會受到影響。

如果企業本來就有集中式 Log、SIEM 或 SOC，就可以把重要事件整合進去，至少不要讓所有關鍵 Audit Trail 只存在一台自己也能修改的主機上。

Day 3 治理面一直在講「出事之後要能交代」，真正發生事件的時候，靠的就是這些留下來的紀錄。

系統會留，但人會走

還有一個很容易被忽略的問題：人會走

今天做這個工具的人可能很熱心，也很願意維護，但半年後他可能調單位、換工作，甚至單純沒有時間再維護。

那這個工具怎麼辦？

所以前面 Day 10 在講規範時，我就有提到 Owner 的概念。工具不能只知道「誰做的」，還要知道「現在誰負責」。Owner 異動時要能轉移，真的沒有人接，就要評估下架，而不是讓一個沒有人負責的系統一直留在那裡。

這也是為什麼治理不能只管「上架」：

有上架，就一定要有下架。

定期回頭看，它還該不該留著

最後是定期複查。

我自己的平台如果真的做到正式環境，會希望定期回頭看：這個工具還有人用嗎？Owner 還在嗎？權限還合理嗎？套件有沒有新的已知漏洞？原本核准的用途有沒有改變？

已經沒有人使用的工具就應該評估下架，需要更新的就回到變更流程重新處理。

不然平台剛開始可能只有十個工具，看起來每一個都很清楚；幾年之後變成幾百個，裡面一堆沒人知道誰負責、也不知道還有沒有人在用，最後又回到一開始 Shadow IT 的問題。

清冊不是越長越厲害，而是裡面的東西要真的有人管。

小結

到這裡，SSDLC 的六個階段就全部走完了。

需求、設計、開發、測試、部署、維運，沒有一個是因為 AI 才突然出現的新東西，全部都是軟體開發本來就在做的事情。

差別只在於：以前很多事情是工程師自己做，現在變成人跟 AI 一起做。而且 AI 動作真的很快，快到你如果沒有先把規矩、邊界和流程訂好，它可能已經先把東西做出來了。

前面一直提到的「好心人」，很多時候不是故意想繞過流程，而是他原本就不是軟體工程師，也不一定知道一個工具從「做得出來」到「可以正式提供別人使用」，中間其實還有這麼多事情。

這也是我前面一直在想的平台要補上的東西：需求時把基本資料與風險留下來、上傳後自動掃描、審核通過才能發布、版本變更重新審查、Owner 異動能追蹤，最後不用了也能正式下架。

不是要求每一個好心人都先變成資深工程師，而是把原本靠工程師經驗記得的事情，盡量變成平台流程的一部分。

回頭看前面一路做的事情，其實就是：

需求時先想清楚。

設計時先把風險找出來。

開發時切小、確認、留下版本。

測試時正常的要成功，不正常的要失敗。

部署時把正式環境守住。

維運時持續追蹤變更、漏洞、紀錄與 Owner。

六站講完了。

但還有一個問題，從前面一直留到現在沒有回答。

前面需求可以問 AI、架構可以讓 AI 幫忙規劃、程式可以讓 AI 寫、測試可以讓 AI 產生，連部署腳本和維運工作 AI 都可以協助。

既然它什麼都可以幫忙，那為什麼我還一直在流程中間留下「人」？